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REMARKS 

Claims 1, 8, and 14 have been amended. Claims 1 -20 are pending in this Application. 
Reconsideration and further examination is respectfully requested. 

QirrenLStatus of Outstanding Rejections 

A phone conference was held between the Applicant's attorney and the Examiner on, 
October 19, 2005. The Examiner confirmed that the rejections attached to the Office Action of 
July 20, 2005 mistakenly reflected the rejections in the Office Action of December 13, 2004. 
The Examiner stated that he intended to attach the rejections in the most recent Office Action of 
May 1 1, 2005, The Applicant's attorney therefore addresses the rejections of May 1 1, 2005 in 
this response. 

Claim Rejections - 35 USC $ \Q $ 

Claims 1, 2, 4, 5, 8, 9, 1 1, 14, 15, 17 and 18 were rqected under 35 U.S.C 103(a) as being 
anticipated by the Cisco white paper "COPS for R$VF" and Gai et aL (US Patent 6,167,445). 
This rejection is respectfully traversed. 

The Applicant's exemplary Claim 1 sets forth: 

"A method of a computer network in establishing communication between a first 
network device and a second network device, the network including a policy 
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device that controls policy data relating to the communication, the method 
comprising: 

storing policy data in a storage device accessible by a third network device, 
the policy data being: 

(i) provided by the policy device in response to a resource 
reservation request message from the first network device to the second network 
device, and 

(ii) specifically related to communication between the first 
network device and the second network device; 

receiving with the third network device a confirmation message sent by the 
second network device in response to the resource reservation request message, 
the confirmation message indicating that the second network device is prepared to 
have communications with the first network device; and 

forwarding from the third network device to the first network device the 
. stored policy data with the confirmation message ," 

The Applicant's claimed invention applies to resource reservation communications 
between a first and second network device. Resource reservation protocols are used to reserve a 
resource $uch as bandwidth for a particular flow of traffic between two network devices. Hie 
Applicant provides an efficient and scalable method of further applying policies during the 
resource reservation process in a manner that offloads a policy device. Accordingly, a policy 
device provides policy data to a third network device in response to a resource reservation 
request message from the first network device. This policy data is stored in the third network 
device. Then, in response to receipt of a confirmation message from the second network device, 
the third device forwards the stored policy data and the confirmation message to the first 
network device. 

According to one implementation of the Applicant's invention, the policy device may be 
a COPS server. The third network device may be a router. The first and second network devices 
may be access devices. In response to an RSVP request message from the first network device, 
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the router stares policy data provided by the COPS server. Then, in response to an RSVP 
reservation message from the second network device, the router sends the reservation message 
and the stored policy data to the first network device. Note the router does not need to access 
the policy device in response to the RSVP reservation message as in the prior art; rather, the 
router sends the RSVP reservation message containing the policy data directly. 

In order to establish a prima facie case of obviousness, the prior art references when 
combined must teach or suggest all the claim limitations. Furthermore, there must be some 

suggestion or motivation to modify a reference or combine reference teachings. The. Applicant 

maintains that neither of these thresholds has been met. 

1 . The Combination of References Fails to Teach or Suggest the Applicant 's Claimed 
Invention 

The Applicant maintains that the combination of the COPS for RSVP paper with Gai 
fails to teach or suggest the Applicant's claimed invention including the steps of "storing policy 
data in a storage device accessible by a third network device, the policy data being: (i) provided 
by the policy device in response to a resource reservation request message from the first network 
device to the second network device, and (ii) specifically related to communication between the 
first network device and the second network device; and "forwarding from the third network 
device to the first network device the stored policy data with the confirmation message". 

The COPS for RSVP paper describes a typical prior art COPS implementation wherein 
all RSVP messages are forwarded by the router to the COPS server, and then from the COPS 
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server back to the router. That is, all policies are stored at the COPS server. The Applicant's 
invention, on the other hand, causes the policy data to be stored at tbe router (or in storage 
accessible by the router) in response to a message from the first network device, so that the 
router need not access the COPS server twice. The router can thus send a reservation message 
and the stored policy data directly to a network device without accessing the COPS server. 

The COPS for RSVP paper does not suggest that any policies stored in the policy device 
should also be stored in a third network device (e.g. router). Thus, the COPS for RSVP paper 
. cannot suggest that a confirmation message (e.g. "reservation message") including policy .data, 
should be sent from the third network device as claimed, because no such third network device 
storing policy data exists. The COPS for RSVP paper therefore clearly fails to teach or suggest 
the Applicant's claimed invention including the steps of "storing policy data in a storage device 
accessible by a third network device, the policy data being: (i) provided by the policy device in 
response to a communication request message from the first network device to the second 
network device, and (ii) specifically related to communication between the first network device 
and the second network device; and "forwarding from the third network device to the first 
network devic e the stored p olicy data with the con firmation message ". 

Gai discloses a method of using a central policy server (322) for configuring intermediate 
devices (e.g. router 318). Gai discloses only that configuration information can be sent from a 
policy server to a router. Gai does not address the problem solved by the Applicant's invention 
- that is, Gai does not address resource reservation protocols or implementations. Armed with 
the knowledge provided by COPS for RSVP and Gai, one understands how the RSVP protocol 
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works, and one learns that policy information can be transferred from a policy server to a router. 
There is no reasonable way to combine this information to arrive at the conclusion that the RSVP 
protocol of COPS for RSVP should be modified to eliminate a step by transferring policy 
information in a resource reservation (e.g. confirmation) message from a third network device (e.g. 
router) directly to a requesting device. 

It is clear that the COPS for RSVP paper does not suggest any way or reason for 
forwarding policy information in a confirmation message from a third network device to the first 
■ - - network device. Similarly, Gai does not add any further information to. suggest any. way or 
reason for forwarding policy information in a confirmation message from a third network device 
to the first network device. It is therefore not possible to combine these references to suggest 
that a resource reservation method should operate in this manner, as the Applicant has claimed. 

2. No Motivation to Combine 

The Applicant asserts that there is no reasonable motivation to combine the COPS for 
RSVP paper with Gai to arrive at the Applicant's claimed invention including the steps of 
"staring policy data in a storage device accessible by a third network device, the policy data 
being: (i) provided by the policy device in response to a resource reservation request message 
from the first network device to the second network device, and (ii) specifically related to 
communication between the first network device and the second network device; and "forwarding 
from the third network device to the first network device the stored policy data with the 
confirmation message". 
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Faced with the problem of reducing a policy server bottleneck such as that described in 
COPS for RSVP wherein the policy server must be accessed before a confirmation message is 
sent from a second to a first network device, one is motivated to reduce traffic between the router 
and the policy server during resource reservation message exchanges. Gai suggests only that 
policy information can be transferred between a policy server and a router. Gai does not address 
resource reservation, nor does Gai address the problem of reducing traffic between a router and a 
policy server. Thus, one skilled in the art would not be motivated to consider Gai, nor would one 

be motivated to combine Gai with COPS for RSVP to arrive at the Applicant's claimed invention . 

including the steps of "storing policy data in a storage device accessible by a third network 
device, the policy data being: (i) provided by the policy device in response to a communication 
request message from the first network device to the second network device, and (ii) 
specifically related to communication between the first network device and the second network 
device; and forwarding from the third network device to the first network device the stored 
polic^data with the confirmation message". 

For all the reasons set forth above, the Applicant respectfully asserts that claim 1 and its 
dependent claims 2, 4, and 5 are in condition for allowance. The Applicant's independent claims 
8 and 14 include limitations similar to those of claim 1. The Applicant therefore respectfully 
asserts that claims 8, 9, 11, 15, 17, and 18 are in condition for allowance for the same reasons as 
set forth with regard to claim 1. 

Claims 3, 10, and 16 were rejected under 35 U.S*C_ 103(a) as being unpatentable in view 
of the combination of the Cisco white paper "COPS for RSVP" and Gai and "Internet Group 
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Management Protocol, Version 2" ("IGMP")- This rejection is respectfully traversed. Claims 3, 
10, and 16 depend from claims 1, 8, and 14 respectively. IGMP adds nothing further to COPS 
for RSVP and/or Gai to teach or suggest the invention as set forth in the independent claims. The 
Applicant therefore respectfully asserts that claims 3, 10, and 16 are in condition for allowance. 

Claims 6, 12, and 19 were rejected under 35 U.S.C. 103(a) as being unpatentable in view 
of the combination of the Cisco white paper ''COPS for RSVP" and Gai and "An Architecture 
for Differentiated Services" ("DSCP")- Tbk rejection is respectfully traversed. Claims 6, 12, 
and 19 depend from claims 1 * 8, and 14 respectively. DSCP. adds nothing further to COPS for 
RSVP and/or Gai to teach or suggest the invention as set forth in the independent claims. The 
Applicant therefore respectfully asserts that claims 6, 12, and 19 are in condition for allowance. 

Claims 7, 13, and 20 were rejected under 35 U.S.C. 103(a) as being unpatentable in view 
of the combination of the Cisco white paper "COPS for RSVP" and Gai and "The Standards 
Watch: 802, lp signaling marking" (802.1p"). This rejection is respectfully traversed. Claims 7, 
13, and 20 depend from claims 1, 8, and 14 respectively. 802. lp adds nothing further to COPS 
for RSVP and/or Gai to teach or suggest the invention as set forth in the independent claims. The 
Applicant therefore respectfully asserts that claims 7, 13, and 20 are in condition for allowance. 

The Applicant has made a diligent effort to place the claims in condition for allowance. 
However, should there remain unresolved issues that require adverse action, it is respectfully 
requested that the Examiner telephone the undersigned, Applicants* Attorney at 978-264-6664 so 
that such issues may be resolved as expeditiously as possible. 
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For these reasons, and in view of the above amendments, this application is now 
considered to be in condition for allowance and such action is earnestly solicited. 

Respectfully Submitted, 



Date Mary Steubing, Reg. No. 37,946 

Attorney/Agent for Applicants) 
Steubing McGuinness & Manaras LLP 
125 Nagog Park Drive 
Acton, MA 01720 
.(978)264-6664 

Docket No. 120-198 
Dd; 5/11/2005 
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